Механизм репликации FreeIPA

Репликация — это процесс, в ходе которого содержимое каталога синхронизируется между серверами, за счет чего достигается целостность данных или так называемая конвергентность. В службе каталога FreeIPA используется протокол «DS 5.0 multi-supplier incremental replication protocol», в котором учитываются отдельные положения (RFC3384).

Каждая Реплика FreeIPA является Мастером, т.е. доступна на запись, и с ее помощью можно вносить изменения в каталог. Разрешение конфликтов основано на использовании меток времени, поэтому для корректной работы механизма крайне важно, чтобы время было синхронизировано между всеми серверами и ни в коем случае не уходило вперед/назад более, чем на сутки, иначе для устранения проблемы искажения времени (too much time skew) может потребоваться восстановления контроллеров из резервной копии.

Соглашения о репликации

На низком уровне репликация проходит по модели Ведущий-Ведомый (Master-Slave), в рамках которой Сервер, передающий изменения, называется Поставщиком, а Сервер, принимающий изменения, называется Потребителем. По итогам репликации на Потребителе формируется полная копия данных каталога, поэтому его также называют Репликой.

Для работы механизма репликации требуется заранее определить топологию домена через создание Сегментов и Соглашений о репликации. Сегмент топологии (Topology segment) определяет связь между двумя узлами и является информацией, которая реплицируется в домене между всеми контроллерами, а Соглашения о репликации хранятся только на Поставщике и содержат настройки для подключения к Потребителю. Таким образом, на каждый двусторонний Сегмент приходится по два Соглашения.

Для управления топологией на портале управления нужно перейти к странице Управление доменом > Сайты и службы > Соглашения о репликации, см. Соглашения о репликации контроллера домена dc-1 с резервным контроллером dc-2.

Рисунок 102 Соглашения о репликации контроллера домена dc-1 с резервным контроллером dc-2

В интерфейсе сущности названы Соглашениями, но, по сути, это Сегменты топологии. Соответствующие Соглашения о репликации будут созданы на каждом из контроллеров домена автоматически, как только ими будет получена информация о соответствующем Сегменте топологии, за что отвечает плагин топологии (IPA Topology Configuration).

Порядок решения конфликтов репликации

Репликация всегда инициируется Поставщиком, а не Потребителем (т.е. работает по модели Push). Алгоритм основан на использовании журнала изменений, который хранится в отдельной базе данных, для ALSE до версии 1.7.4 см. файл «/var/lib/dirsrv/slapd-ALD-COMPANY-LOCAL/cldb/*.db», для ALSE 1.7.4 и выше см. файл /var/lib/dirsrv/slapd-ALD-COMPANY-LOCAL/db/userRoot/replication_changelog.db.

Открыть файл можно командой dbscan -f:

dbscan -f
/var/lib/dirsrv/slapd-ALD-COMPANY-LOCAL/db/userRoot/replication_change
log.db

В сеансе репликации Поставщик связывается с Потребителем, запрашивает у того сводную информацию о состоянии его репликации (так называемую таблицу RUV, Replica Update Vector), чтобы определить, есть ли у него для Потребителя более свежие данные, которые можно было бы передать, и запускает передачу данных. В случае изменения одного и того же атрибута на двух разных контроллерах домена, при репликации приоритет будет выше у последнего изменения по времени.

В случае, когда на нескольких контроллерах одновременно создаются записи с одинаковыми DN, автоматический механизм разрешения конфликтов оставит только ту запись, которая была создана раньше других по метке времени. Остальные записи будут переименованы и скрыты. К имени записи добавляется атрибут nsuniqueid, например, дубликат учетной записи пользователя ivan.kuznetsov будет называться nsuniqueid=7341f021-20b331ee-a3ef96ae-a91d3705+uid=ivan.kuznetsov,cn=accounts,dc=ald,dc=company,dc=lan.

Дополнительно таким записям назначается атрибут nsds5ReplConflict, чтобы их было легко найти в каталоге:

ldapsearch -H ldap://localhost:389 -x -D "cn=Directory Manager" -W -b "cn=users,cn=accounts,dc=ald,dc=company,dc=local" -s one -a always -z 1000 "(|(objectClass=subentry)(objectClass=ldapSubentry))" "hasSubordinates" "objectClass"

Если создать пользователя на одном сервере, а на другом сервере удалить структурное подразделение, в котором этот пользователь был создан, то на уровне репликации LDAP конфликт не произойдёт, т.к. отношение пользователя к структурному подразделению в ALD Pro реализуется через атрибут rbtadp, а не через связь родительской и дочерней записи. Пользователь не будет отражаться в каком-либо структурном подразделении. Но будет присутствовать в списке всех пользователей.